not convinced -- prove me wrong

Hi! I'm not sure I understand specifically what I should prove wrong, but I can break down some facts:

• Debian has a deprecation bug about haveged
• globaleaks/GlobaLeaks has dropped it Deprecate haveged on systems running kernel >= 5.6 globaleaks/whistleblowing-software#3184
• Haveged author is discouraging against his package usage, experimenting himself is haveged still useful/relevant? jirka-h/haveged#57 (comment)

To sum it up:

• it adds no performance advantage
• it takes space
• Some distros already removed from default installation/startup (also whistleblowing-supporting ones)
• Linux mainline integrated HAVEGE algorithm since version 5.4 (many releases ago)
• removing it doesn't break linux from working while saving space
• users can install it manually should they see fit
• Author himself discourages usage as daemon
• Debian is discussing about removing the package from their repo after bookworm

To be honest the initial material listed offered a decent overview, nevertheless I'm not expecting or demanding removal: just proposing it - no offence taken should you decide otherwise :)

Grazie 🙏🏻
Ale

Excellent. I'm 99% convinced, except: does it all apply to armhf/arm64/riscv64? A cursory look revealed x86 arch stuff so I'm reticent. I've been bit by lack of entropy and random, really hard to diagnose hangs too many times so excuse my trauma showing.

But I've my reasons: see the "default scheduler" fiasco/success from a few weeks ago.

Excellent. I'm 99% convinced, except: does it all apply to armhf/arm64/riscv64? A cursory look revealed x86 arch stuff so I'm reticent. I've been bit by lack of entropy and random, really hard to diagnose hangs too many times so excuse my trauma showing.

But I've my reasons: see the "default scheduler" fiasco/success from a few weeks ago.

Now I understand the root doubt, thanks: there are some similar doubts on the lkl thread along with some testing code and some benchmark runs to prove robustness.

Now, if logic serves me well (and I don't take it for granted as probabilistic/deterministic stuff is complex), if HAVEGE algorithm isn't fit for armhf/arm64/riscv64, it shouldn't matter if it's running off a library/daemon or from kernel

The linked readme states:

It means that HAVEGED service is now less relevant. However, it's still useful in the following situations, when you

• need randomness early in the boot process, before the CRNG in the Linux kernel gets fully initialized.

I believe U-Boot can do this for us. Need to have a look at what e.g. kaslrseed actually provides.

• want to deploy an additional entropy source. HAVEGED now inserts entropy into the kernel every 60 seconds, regardless of the entropy level reported by Linux Kernel. It does not affect the /dev/random read speed but it diversifies the entropy sources, making the Linux Kernel CRNG more robust.

• you are looking for userspace RNG to generate random numbers. See man -S8 haveged for examples or try running haveged -n 0 | pv > /dev/null

Users can install their fav tool for RNG if needed

• and last but not least, most Linux installations are still running on the older kernel versions.

Irrelevant today.

The project seems to not have been updated in a while. Looks to me as dropping this package is totally fine.

Did a few tests. All my systems run fine without haveged (and have been so for a few years, actually -- silly me)
Adding it does not increase available entropy or its quality at all.
Go ahead -- I'm fully convinced.

Did a few tests. All my systems run fine without haveged (and have been so for a few years, actually -- silly me) Adding it does not increase available entropy or its quality at all. Go ahead -- I'm fully convinced.

🙏🏻

I believe U-Boot can do this for us. Need to have a look at what e.g. kaslrseed actually provides.

Actually I'm interested too - tried to delve a bit it seems it needs some nodes in DTB - with a random seed coming from bootloader kaslr would kick in - whatever that is - possibly some randomization of kernel memory
Quite out of my league to fully grasp it

I believe U-Boot can do this for us. Need to have a look at what e.g. kaslrseed actually provides.

Actually I'm interested too - tried to delve a bit it seems it needs some nodes in DTB - with a random seed coming from bootloader kaslr would kick in - whatever that is - possibly some randomization of kernel memory Quite out of my league to fully grasp it

Ah I didn't know that this needed a special device tree node. RK35** devices do have a hardware RNG generator, so maybe this could be used somehow in U-Boot?

@ColorfulRhino - it's implemented in some nanopi board - look at this pr #4352
Seems an u-boot command that should be enabled/compiled in

@ColorfulRhino - it's implemented in some nanopi board - look at this pr #4352 Seems an u-boot command that should be enabled/compiled in

Yeah this is a requirement, U-Boot has to be compiled to have the kaslrseed command available AND the command needs to be called in the script.

The PR you linked actually is not the best implementation imo since on so many boards it currently does output an error message on boot like "error: kaslrseed not available" 😆

What's your cat /proc/sys/kernel/random/entropy_avail by the way?

On NanoPi R6C it seems stuck on 256 which is really low (without this PR applied).

What's your cat /proc/sys/kernel/random/entropy_avail by the way?

On NanoPi R6C it seems stuck on 256 which is really low (without this PR applied).

nanopi-r5c

 18:13:11 up 18:26,  0 user,  load average: 1,09, 1,28, 1,33
256

smeels like hardcoded
No change with haveged daemon running - makes no sense

smeels like hardcoded No change with haveged daemon running - makes no sense

Yeah this is unrelated to haveged, I just commented here because the topic seemed similar :)

In theory, the hardware based RNG generator should be active on RK35xx in the edge kernel. Maybe something is not correct here. Investigation needed, I will open an issue.

smeels like hardcoded No change with haveged daemon running - makes no sense

Yeah this is unrelated to haveged, I just commented here because the topic seemed similar :)

In theory, the hardware based RNG generator should be active on RK35xx in the edge kernel. Maybe something is not correct here. Investigation needed, I will open an issue.

on my nanopi I'm running current 6.6 - kali patches aren't yet ported to post-6.8
Will test a vanilla kernel later today after work :)

on my nanopi I'm running current 6.6 - kali patches aren't yet ported to post-6.8 Will test a vanilla kernel later today after work :)

It's probably the same on 6.10 :)

Maybe this behaviour is wanted, see #6806

Also, apologies, I did not want to hold up this PR. It's still ready to merge, the discussion has not much to do with haveged. We can move the discussion to #6806

smeels like hardcoded No change with haveged daemon running - makes no sense

Yeah this is unrelated to haveged, I just commented here because the topic seemed similar :)

In theory, the hardware based RNG generator should be active on RK35xx in the edge kernel. Maybe something is not correct here. Investigation needed, I will open an issue.

Not a big fan of HWRNG's as unlike SW, they cannot be audited...

The current RNG in the kernel is more that sufficient

Not a big fan of HWRNG's as unlike SW, they cannot be audited...

True, but you can only do so much with software.

The current RNG in the kernel is more that sufficient

I'm not sure if HWRNG on Rockchip automatically replaces software RNG if enabled in the kernel config.

Not a big fan of HWRNG's as unlike SW, they cannot be audited...

True, but you can only do so much with software.

The current RNG in the kernel is more that sufficient

I'm not sure if HWRNG on Rockchip automatically replaces software RNG if enabled in the kernel config.

IIRC it just creates the device, e.g. /dev/hwrng

To actually use it, one has to also include the rng-tools package and configure rngd to use the hwrng device.

https://github.com/nhorman/rng-tools

Otherwise the kernel should always prefer the internal software based RNG

As I mentioned, things like HWRNG's and onboard crypto accelerators/offload are always a concern... how random are they, and how can one confidently test it? If it is even slightly less than random, it's a big security risk.

Anyways, the other benefit of just using the kernel's RNG is that it's just a lot less maintaining - and that's always a win.

Remember that haveged was there to address issues with /dev/random (it's blocking) and things like VM's that are slow to fill the pool - the RNG in 5.19 addresses the same concerns.

Adding it does not increase available entropy or its quality at all.

Or did you test entropy quality?